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PROTECTION D'UN PROGRAMME EN ATTENTE D 1 EXECUTION DANS UNE 
MEMO IRE DTILISEE PAR UN MICROPROCESSEDR 

La present e invention concerne le domaine des 
microprocesseurs et plus particulierement les circuits 
multitaches capables d'executer, au moins de ce que voit 
1 'utilisateur, plusieurs programmes simultanement . En pratique, 
une seule instruction d'un programme est traitee a chaque 
instant par une unite cent rale de traitement mais plusieurs 
programmes ou trongons de programme sont stockes dans une 
memoire vive accessible par 1" unite centrale qui transfere des 
lignes du programme a exe cuter vers une memoire cache qui lui 
est affectee. 

La figure 1 illustre, de fagon tres schema tique et 
sous forme de blocs, un exemple d 1 architecture simplifiee du 
type auquel s 1 applique la presente invention. Une unite centrale 
de traitement 1 (CPU) equipee d'une memoire cache 2 (CACHE) est 
connectee a un ou plusieurs bus 3 de communication (donnees, 
adresses, commandes) avec des elements peripheriques . Parroi ces 
elements peripheriques, une memoire vive 4 (RAM) destinee a 
contenir les donnees (operandes) des programmes en cours de 
traitement ainsi que les lignes de code de ces programmes (au 
moins par blocs) est connectee au bus 3 . En pratique, les 
programmes contenus dans la memoire 4 proviennent generalement 
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d'une memoire de masse - 5 (MMEN) , par exemple, un disgue dur. 
Cette memoire de masse contient les programmes susceptibles 
d'etre executes par 1' unite centrale ainsi que des dormees 
sauvegardees lorsque ces programmes ne sont pas en cours 
5 d T execution. Bien entendu, plusieurs memoires de masse (CDROM, 
disquette etc . ) peuvent etre connectees au bus 3 . 

Pour etre capable d'executer plusieurs applications ou 
programmes differents stockes temporairement dans la memoire 4, 
1' unite centrale 1 doit disposer d'une table de correspondance 

10 entre des adresses dites virtuelles du programme qui sont 
independantes de son lieu de stockage et des adresses dites 
physiques correspondant aux adresses physiques dans la memoire, 
par exemple la' memoire 4, ou sont stockees les differentes 
lignes du programme. Cette table de correspondance est 

15 generalement stockee dans des registres tampon et generalement 
designee par son appellation anglo-saxonne TLB (Translation Look 
Aside Buffer) . 

La figure 2 illustre, de fa<?on tres schematique et 
f onctionnelle, une table de correspondance 10 et les echanges 

2 0 entre la memoire cache ou registre contenant cette table et les 
differents elements y ayant recours. 

Cote unite centrale de traitement 1, a chaque fois 
qu'une instruction d'un programme stocke dans la memoire vive 4 
doit etre executee, I'appel de cette instruction s'effectue en 

2 5 utilisant l r adresse virtuelle VirtAD de cette instruction 

correspondant a l'adresse contenue dans le programme. Cette 
adresse virtuelle est convertie par la table 10 en une adresse 
physique PhysAD ou se trouve cette instruction dans la memoire 
vive 4 . La memoire 4 f ournit alors 1 1 instruction correspondante 

3 0 sur le bus (3, figure 1) a destination de l T unite centrale. 

Si la table 10 ne contient pas la correspondance entre 
les deux adresses, 1 'unite centrale ou plus precisement un 
programme de calcul (bloc 11, CALC) de son systeme 
d 1 exploitation calcule une nouvelle ligne de correspondance 
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entre adresse virtuelle et adresse physique, et 1 1 inscrit dans 
la table 10. 

A chaque fois qu'une application contenue dans la 
memoire vive 4 doit etre executee par 1' unite centrale, le 
systeme d 1 exploitation prend la main et utilise ses structures 
internes pour calculer la table de correspondance pour le 
programme concerne. 

La figure 3 illustre le fait que deux applications 
differentes APPL1 et APPL2 stockees dans la memoire vive 4 a des 
adresses physiques differentes (PhysAD(k) a PhysAD(m) pour le 
premier programme et PhysAD(n) a PhysAD(p) pour le deuxieme 
programme) se partagent des adresses virtuelles identiques 
(VirtAD(l), VirtAD(2), VirtAD(i) , etc). A chaque. fois- qu'un 
programme passe en avant plan, c'est-a-dire en execution par 
l 1 unite centrale 1 (le cas echeant apres transfert dans la 
memoire cache 2), sa table de correspondance 10 est utilisee 
pour convertir ses adresses virtuelles en adresses physiques 
dans la memoire 4 . 

Pour des questions de securite dams le deroulement des 
programmes, il est important que deux adresses virtuelles 
identiques de deux applications differentes ne pointent pas vers 
la meme adresse physique dans la memoire 4. En effet, cela 
permet de proteger le code du programme ainsi que les donnees 
des applications entre elles. Par exemple, si tine donnee 
sensible (quantite secrete, resultat secret, etc.) d'une 
premiere application est situee dans une adresse physique 
conrprise entre les adresses k et m dans la memoire 4 alors 
qu'elle se voit attribuer une adresse virtuelle i, il ne faut 
surtout pas qu'une autre application puisse acceder a l 1 adresse 
physique correspondante en reutilisant 1' adresse virtuelle i. 
Dans une architecture du type de ,celle de la figure 2, il faut 
reinitialiser la table de correspondance a chaque fois que l'on 
passe d'une application a une autre. Cela impose de recalculer 
la table de correspondance a chaque fois qu r une application 
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passe en execution de premier plan, c'est-a-dire qu'une de ses 
instructions doit etre executee par 1' unite centrale. 

Un inconvenient evident est que cela prend du temps. 

La figure 4 illustre, de facon tres schematigue, 
1 • architecture d'une solution classique permettant d'eviter de 
recalculer la table de correspondence a chaque fois qu'une 
application passe en premier plan. Cette solution utilise un 
champ supplement aire de la table 10 de correspondence qui 
contient, pour chaque ligne, un identifiant ASID de 
1' application en plus des adresses virtuelle et physique. Cela 
permet, en principe, d'eviter qu'une application utilise la 
correspondence d'une adresse physique d'une autre. 

Pour la mise en oeuvre de cette solution, le circuit 
utilise un registre 20 (ASIDREG) contenant 1 ' identifiant de 
1' application courante. Ce registre est un registre d'etat de 

1 1 unite centrale 1 . 

Cette solution presente l'avantage par rapport a celle 
de la figure 2, de ne pas necessiter de reinitialiser ou vider 
la table de correspondence a chaque fois que l'on change de 
tache de premier plan. 

Dn inconvenient reste toutefois que c'est le systeme 
d' exploitation qui attribue les identifiants ASID aux 
differentes applications lorsqu'une application est chergee en 
memoire vive pour execution. La zone de meraoire vive 4 allouee a 
vine application suspendue (en arriere plen) devient per 
consequent plus vulnerable a des attaques eventuelles. En effet, 
a partir du moment ou la table de correspondance n'est pas 
integralement recalculee lorsque 1 ' application passe en premier 
plan, il est possible de remplacer le memoire vive per un 
emuleteur, ou de modifier les signaux sur le bus 3, afin de 
modifier un code operetoire d'une application en arriere plan et 
y inserer une instruction pirate (type virus ou "cheval de 
Troie") . Par suite, lorsque 1 ' applicetion repesse en premier 
plan, elle pourra alors acceder aux adresses physiques restees 
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presentes dans la table de correspondance lors de I 1 execution 
precedente de 1 'application (avant qu'elle soit modifiee) . 

Cette vulnerability d'une application en arriere-plan 
est accrue par le fait qu'il n'est pas necessaire d'etre 
synchrone avec 1 1 unite centrale pour modifier les lignes de 
cette memoire. 

Un probleme similaire se pose pour la memoire de masse 
5 lorsque le programme n'est pas charge integralement en memoire 
vive 4 et que son execution requiert des appels a des lignes en 
domees dans la memoire de masse 5 . 

La present e invention vise a proposer un procede 
d'autorisation d'acces a une table de correspondance qui pallie 
les inconvenient s des solutions connues . En particulier, 
1* invention vise a eviter un recalcul systematique d'une table 
de correspondance a chaque chargement en premier plan d f une 
application a executer, sans pour autant rendre celle-ci 
vulnerable lorsqu'elle est en arriere plan dans une memoire 
vive . . v. 

L f invention vise egalement a proposer une solution qui 
soit compatible avec les utilisations classiques des tables*. :de 
correspondance . 

Pour atteindre ces objets et d'autres, la presente 
invention prevoit un procede d'autorisation d'acces a une table 
de correspondance d'adresses entre une unite centrale de 
traitement multitaches et au moins une memoire contenant 
plusieurs programmes, consistant a calculer, a chaque changement 
de tache de 1' unite centrale, une signature d'au moins une 
partie des lignes d ' instruction du programme et a verifier la 
conformite de cette signature avec une signature enregistree 
lors d'une execution precedente du programme concerne. 

Selon un mode de mise en oeuvre de la presente 
invention, ladite signature est calculee par la mise en oeuvre 
d'une fonction de Hash. 

Selon un mode de mise en oeuvre de la presente 
invention, ladite memoire est une memoire vive dans laquelle 
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sont chargees des lignes de programme depuis une memoire de 
masse. 

L' invention prevoit egalement un processeur 
d' execution multitaches de plusieurs programmes, exploitant une 
table de correspondence entre des adresses virtuelles des lignes 
des differents programmes et des adresses physiques de ces 
lignes dans au moins une memoire, chaque correspondence etant 
essociee a un identifiant du programme concerne, cerecterise en 
ce qu'il comporte des moyens de calcul d'une signature courante 
a partir d'au moins une partie des lignes du programme dans 
ladite memoire, et des moyens pour comparer cette signature a 
1 • identifiant du programme stocke dans la table de 
correspondence . 

Selon un mode de realisation de la presente invention, 
l'identite de la signature et de 1 ' identifiant du programme 
autorise 1' unite centrale a executer 1 ' instruction du programme 
concerne . 

Ces objets, carecteristiques et avantages, ainsi que 
d'autres de la presente invention seront exposes en detail dans 
la description suivante de modes de realisation particuliers 
faite a titre non limitatif en relation avec les figures jointes 
parmi lesquelles : 

les figures 1 a 4 decrites precedemment sont destinees 
a exposer 1 • etat de la technique et le probleme pose ; et 

la figure 5 represente, de fagon tres schemetique et 
sous forme de blocs, un mode de realisation d'une architecture 
de microprocesseur mettant en oeuvre le procede d ' autorisation 
d'acces d'une table de correspondence selon 1' invention. 

Les memes elements ont ete designes par les memes 
references aux differentes figures. Pour des raisons de clarte, 
seuls les etapes de procede et les elements du processeur qui 
sont necessaires a 1' expose de 1' invention ont ete representes 
aux figures et seront decrits par la suite. En particulier, le 
calcul de la table.de correspondence en elle-meme n'e pas ete 
detaille et ne feit pas 1'objet de la presente invention, celle- 
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ci pouvant etre mise en oeuvre avec les outils de calcul 
utilises classiquement . 

Une caracteristique de la presente invention est de 
calculer, a chaque changement de contexte (passage en avant plan 
5 d'une nouvelle application), 1 1 identif iant de 1 1 application au 
moyen d'un algorithme executant une f one t ion de Hash ou analogue 
calculant une signature d'au moins une partie du code de 
1 'application stocke en memoire vive et/ou en memoire de masse. 

Une autre caracteristique de 1 1 invention est de 

10 verifier la conformite de cette signature courante calculee, par 
rapport a une signature de reference calculee precedemment et 
enregistree dans la table de correspondance . Le calcul de la 
signature de reference s'effectue a chaque calcul d'une nouvelle 
correspondance entre une adresse virtuelle et une adresse 

15 physique. Cette signature reste toutefois tou jours la meipe pour 
une meme application. 

La figure 5 illustre, de fagon tres schematique et 
sous forme de blocs, un mode de mise en oeuvre de la presente 
invention. La representation de la figure 5 expose 

2 0 principalement les liaisons fonctionnelles entre les differents 
elements . 

L ■ invention exploite une architecture du type de celle 
decrite precedemment en relation avec la figure 4, c f est-a-dire 
exploitant un identif iant ASID de 1 1 application ou programme 

2 5 associe a chaque ligne de correspondance de la table 10 entre 
une adresse virtuelle VirtAD et une adresse PhysAD physique . 
Tou jours comme precedemment, cette table de correspondance 10 
sert a convertir des adresses virtuelles d'une application 
requise par une unite cent rale de traitement 1 (CPU) pourvue 

30 d r un registre 20 d 1 identif iant d 1 application (ASIDREG) , en une 
adresse physique PHYSAD d'une memoire vive 4 dans laquelle est 
stockee 1 'application concerhee. L 1 unite centrale de traitement 
comporte des moyens materiels ou logiciels (bloc 11, CALC) pour 
faire calculer, par son systeme d 1 exploitation, les adresses 
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physiques soit au chargement d'une application soit lorsqu'une 
adresse virtuelle est appelee pour la premiere fois. 

Selon la presente invention, a chaque fois qu'une 
application (par exemple, un programme ou un sous -programme) 
contenu dans la memoire 4 (ou dans une memoire de masse non 
representee) doit passer en premier plan, c'est-a-dire qu'au 
moins une de ses instructions doit etre executee par 1' unite 
centrale 1, on calcule une signature (bloc 30, HASH) d'au moins 
une partie des lignes du programme stocke dans la memoire 4. 
Cette signature fournit un identifiant d * application courant 
(CURASID) stocke dans le registre 20. Le contenu de ce registre 
20 est alors compare (bloc 32, COMP) a 1 • identifiant ASID stocke 
sur la ligne de la table 10 correspondant a 1 ' application 
concernee que l'on veut utiliser. Le resultat de cette 
comparaison permet de verifier que le code operatoire de 
1 ' application n'a pas ete modifie dans la memoire vive alors que 
cette application se trouvait en arriere plan. Le bloc de 
comparaison 32, qu'il soit materiel ou logiciel, fournit un 
signal d'autorisation ou d' authentif ication AOT a destination de 
1' unite centrale 1 pour entreprendre les mesures appropriees. En 
pratique, 1 'unite centrale n'executera, ou ne transferera dans 
sa memoire cache pour execution, les instructions du programme 
stocke dans la memoire vive 4 que si le comparateur 32 a 
authentif ie que le code operatoire n'a pas Ste modifie depuis 
son chargement en memoire 4 . 

De preference, le calcul de signature est effectue sur 
une partie fixe et significative du code du programme stocke en 
memoire vive. Par partie fixe, on entend qu'il convient d'eviter 
les lignes contenant des donnees manipulees par le programme 
dont le contenu est done susceptible de changer et de modifier 
la signature alors meme qu'aucun piratage n'a eu lieu. Par 
signif icatif , on entend que plus le nombre de lignes du code 
pris en compte dans le calcul de signature est important, plus 
1 ' authentif ication sera robuste en terme d'ef ficacite. A titre 
d' exemple, on peut calculer la signature en prenant une ligne 
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sur dix, une ligne sur vingt ou une ligne sur trente du code 
operatoire .- 

Un avantage de 1 ' invention est qu'une modification du 
code operatoire d'un programme en arriere plan stocke dans une 
5 memoire vive devient difficile dans la mesure ou il faut 
modifier son code operatoire en respectant la signature dont 
1' algorithme de calcul est en principe inconnu. De preference, 
pour garantir la securite du systeme et pour des raisons de 
rapidite, la fonction de Hash est executee de fagon materielle 
10 en circuit integre. 

L 1 application en cours d 1 execution est forcement dans 
la memoire cache du microprocesseur qui constitue une zone 
consideree comme intouchable , pour un pirate . Ce n 1 est , que 
Ibrsque 1 1 application est en attente dans la memoire vive qu 1 il 
15 existe un risque de piratage. 

On notera que si 1 1 integral ite d ' un programme n'est 
pas transferee de la memoire de masse (5, figure 1) vers la 
memoire vive lors du chargement de 1 'application, le calcul de 
signature peut exploiter des lignes du programme encore 
2 0 presentes dans la memoire de masse. Les modifications a ce qui a 
ete expose ci-dessus sont a la portee de l'homme du metier. 

Un avantage de 1 1 invention est que, sans necessiter un 
recalcul de la table de correspondance 10 a chaque passage en 
premier plan d'une nouvelle application, on garantit. qu 1 un code 

2 5 operatoire ne soit pas pirate alors qu f il est en arriere plan 

dans un traitement multitaches. Bien entendu, le . contenu des 
lignes de la table 10 peut etre ecrase au fur et a mesure de son 
remplissage, comme c'etait le cas classiquement dans la solution 
exposee en relation avec la figure 4 . 

3 0 N'importe quel algorithme classique executant une 

fonction de type Hash peut etre utilise. Parmi les algorithmes 
connus, on citera, par exemple, I 1 algorithme connu sous la 
denomination SHA-1 qui opere sur des blocs de 512 bits et 
fournit une signature de 160 bits en sortie. Pour 1 1 application 
3 5 d'un tel algorithme, le code ou partie de code dont on souhaite 
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obtenir une signature est decoupe en blocs de 512 bits pour 
lesquels on calcule a chaque fois cinq mots de 32 bits 
concatenes correspondant a la signature du bloc. Dans ce cas, on 
peut utiliser, par exemple, un seul mot sur les cinq mots de 32 
5 bits de la signature et additionner les premiers mots de 
plusieurs signatures calculees sur des blocs differents pour 
obtenir le code courant CURASID de 1 ■ application . 

Bien entendu, la presente invention est susceptible de 
diverses variantes et modifications qui apparaitront a l'homme 
10 de l'art. En particulier, le choix de l'algorithme de calcul de 
signature depend pref erentiellement de la taille des 
identifiants d' application utilises dans la table de 
correspondance et du niveau de securite souhaite pour le 
systeme. De plus, la selection des lignes de code operatoire a 
15 prendre en compte dans le calcul de signature est a la portee de 
l'homme du metier a partir des indications f onctionnelles 
donnees ci-dessus. Enfin, si une realisation materielle du 
calcul de signature est preferee, 1 ' invention n'exclut pas une 
realisation logicielle. 
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REVINDICATIONS 

1. Precede d ' autorisation d'acces a tine table de 
correspondance (10) d'adresses entre une unite centrale de 
traitement (1) multitaches et au mo ins line memo ire (4, 5) 
contenant plusieurs programmes, caracterise en ce qu'il consiste 
a calculer, a chaque changement de tache de I 1 unite centrale, 
une signature d'au moins une partie des lignes d 1 instruction du 
programme et a verifier la conformite de cette signature avec 
une signature enregistree lors d f une execution precedente du 
programme concerne . 

2. Precede selon la revendication 1, dans lequel 
ladite signature est calculee par la mise en oeuvre d'une 
fonction de Hash. 

3 . Procede selon la revendication 1 ou 2 , dans lequel 
ladite memo ire est une memoire vive (4) dans laquelle sont 
chargees des lignes de programme depuis une memoire de masse 

4. Processeur d' execution multitaches de plusieurs 
programmes, exploitant une table de correspondance (10) entre 
des adresses virtuelles des lignes des dif ferents programmes, et 
des adresses physiques de ces lignes dans au moins une memoire 
(4, 5) , chaque correspondance etant associee a un identifiant 
(ASID) du programme concerne, caracterise en ce qu'il comporte 
des moyens de calcul d'une signature courante a partir d'au 
moins une partie des lignes du programme dans ladite memoire, et 
des moyens pour comparer cette signature a 1 ' identifiant du 
programme stocke dans la table de correspondance. 

5. Processeur selon la revendication 4, dans lequel 
l ! identite de la signature et de 1 1 identifiant du programme 
autorise l ! unite centrale (1) a executer 1 ' instruction du 
programme concerne. 
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DEPARTEMENT DES BREVETS 
26 bis, rue de Saint Petersbourg 
75800 Paris Cedex 08 

Telephone : 01 53 04 53 04 Telecopie : 01 42 94 86 54 



regue le 09/05/03 

BREVET D'INVENTION, 
CERTIFICAT D'UTILITE 

Code de la propriete intellectuelle-Livre VI 

DESIGNATION D'INVENTEUR(S) PAGE N°1/ 1 
(Si le demandeur n'est pas I'inventeur ou ('unique inventeur) 



N° 55-1328 



Vos references pour ce dossier 

(facultatif) 


B5878 


N° D'ENREGISTREMENT NATIONAL 




TITRE DE L'INVENTION (200 caracteres ou espaces maximum) 

PROTECTION D'UN PROGRAMME EN ATTENTE D'EXECUTION DANS UNE MEMOIRE UTILISEE PAR UN 

MICROPROCESSEUR 


LE(S) DEMANDEUR(S) : 

STMicroelectronics SA 


DESIGNE (NT) EN TANT QUMNVENTEUR(S) : (Indiquez en haut a droite "Page N°1/1" S'i! y a plus de trois inventeurs, utiiisez un 
formulaire identique et numerotez chaque page en indiquant !e nombre total de pages). 


Prenoms & Norn 


Stephan Courcambeck 


ADRESSE 


Rue 


96, avenue du Port 


Code postal et vilie 


83270 SAINT CYR SUR MER, FRANCE 


Societe d'appartenance (facultatif) 


Claude Anquille 


Prenoms & Norn 


ADRESSE 


Rue 


Le Montaiguet 2, 7 rue des Freres Vallon 


Code postal et vilie 


13090 


AIX EN PROVENCE, FRANCE 


Societe d'appartenance (facvltatif) 




Prenoms & Norn 




ADRESSE 


Rue 




Code postal et vilie 






Societe d'appartenance (facultatif) 




DATE ET SIGNATURE (S) 
DU (DES) DEMANDEUR(S) 
OU DU MANDATAIRE 
(Nom et qualite du signataire) 

Michel de Beaumont 

Mandataire n° 92-1 01 6 si 

Le 28 mars 200^^ y/^^^ 





rectification pour les donnees vous concernant aupres de I'lNPI. 



